Proof of concept for extension reserved indices #5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a proof of concept of strong ownership between an extension identity (its service account) and indices that it requested to reserve on the first initialization request. The payload of the REST initialization request would look like:
The primary crux of this is that that SecurityIndexAccessEvaluator is knowledgable of the extensions registry (ExtensionsManager) and checks to see if requested system indices are owned by the extension when evaluating the permissions of a request that interact with a system index.
This strong level of ownership means that extensions cannot meddle with system indices owned by other extensions and there does not need to exist a role in the internal role list that is not intended to be mapped to regular users. By having the configuration in a single place it is also less configuration to get started with an extension since it is a one stop shop in the payload of the initialization request.
Companion PRs:
Core - cwperks/OpenSearch#93
SDK - cwperks/opensearch-sdk-java#1